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AMENDMENTS TO THE CLAIMS 



Please amend Claims 5, 10, and 15 as follows: 



1 1 . (Original) A process for determining latency between multiple servers and a client 

2 across a network in a computer environment, comprising the steps of: 

3 receiving a request for latency metrics on a content server; 

4 wherein said latency metric request specifies a particular client; 

5 providing a latency management table; 

6 wherein said latency management table comprises a list of IP addresses along with 

7 corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 

8 counts, and Round Trip Times (RTT); 

9 looking up the latency metric for said client in said latency management table; 

10 sending said latency metric to the requesting server; 

1 1 wherein the BGP hop count for said client in said latency management table is used 

12 for said latency metric upon the first request for said client; and 

13 wherein the dynamic hop count and RTT data for said client in said latency 

14 management table are used for said latency metric for subsequent requests for 

15 said client. 

1 2. (Original) The process of Claim 1, further comprising the steps of: 

2 sending periodic latency probes to the IP addresses in said latency management 

3 table; 

4 receiving response packets for said latency probes; and 

5 recording the dynamic hop count and latency (RTT) data in said latency 

6 management table. 
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1 3. (Original) The process of Claim 2, wherein periodic latency probes are sent to a 

2 higher level server of a client by masking said client's IP address in said latency 

3 management table. 

1 4. (Original) The process of Claim 1, further comprising the steps of: 

2 receiving requests for a content server address from said client; 

3 sending a latency metric request to the appropriate content servers; 

4 receiving latency metric data from said content servers; 

5 determining the optimal content server for said client; and 

6 sending said optimal content server's address to said client. 

1 5. (Currently Amended) The process of Claim 4, wherein said determining step gathers 

2 the expected latency metrics and uses the inverse relationship of the dynamic hop 

3 counts in said latency metric data in a weighted combination with the RTT in said 

4 latency metric data to determine which latency metric data indicates the optimal 

5 content server. 

1 6. (Original) An apparatus for determining latency between multifile servers and a 

2 client across a network in a computer environment, comprising: 

3 a module for receiving a request for latency metrics on a content server; 

4 wherein said latency metric request specifies a particular client; 

5 a latency management table; 
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6 wherein said latency management table comprises a list of IP addresses along with 

7 corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 

8 counts, and Round Trip Times (RTT); 

9 a module for looking up the latency metric for said client in said latency 

1 0 management table; 

1 1 a module for sending said latency metric to the requesting server; 

12 wherein the BGP hop count for said client in said latency management table is used 

1 3 for said latency metric upon the first request for said client; and 

14 wherein the dynamic hop count and RTT data for said client in said latency 

1 5 management table are used for said latency metric for subsequent requests for 

1 6 V said client. 

1 7. (Original) The apparatus of Claim 6, further comprising: 

2 a module for sending periodic latency probes to the IP addresses in said latency 

3 management table; 

4 a module for receiving response packets for said latency probes; and 

5 a module for recording the dynamic hop count and latency (RTT) data in said 

6 latency management table. 



1 8. (Original) The apparatus of Claim 7, wherein periodic latency probes are sent to a 

2 higher level server of a client by masking said client's IP address in said latency 

3 management table. 

1 9. (Original) The apparatus of Claim 7, further comprising: 
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a module for receiving requests for a content server address from said client; 
a module for sending a latency metric request to the appropriate content servers; 
a module for receiving latency metric data from said content servers; 
a module for determining the optimal content server for said client; and 
a module for sending said optimal content server's address to said client. 

(Currently Amended) The apparatus of Claim 9, wherein said determining module 
gathers the expected latency metrics and uses the inverse relationship of the dynamic 
hop counts in said latency metric data in a v^eighted combination with the RTT in 
said latency metric data to determine which latency metric data indicates the optimal 
content server. 



(Original) A program storage medium readable by a computer, tangibly embodying 
a program of instructions executable by the computer to perform method steps for 
determining latency between multiple servers and a client across a network in a 
computer environment, comprising the steps of: 
receiving a request for latency metrics on a content server; 
wherein said latency metric request specifies a particular client; 
providing a latency management table; 

wherein said latency management table comprises a list of IP addresses along with 
corresponding Border Gateway Protocol (BGP) hop counts, dynamic hop 
counts, and Round Trip Times (RTT); 

looking up the latency metric for said client in said latency management table; 

sending said latency metric to the requesting server; 
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13 wherein the BGP hop count for said client in said latency management table is used 

14 for said latency metric upon the first request for said client; and 

1 5 wherein the dynamic hop count and RTT data for said client in said latency 

1 6 management table are used for said latency metric for subsequent requests for 

17 said client. 

1 12. (Original) The method of Claim 11, further comprising the steps of: 

2 sending periodic latency probes to the IP addresses in said latency management 

.3 table; 
h 

4 receiving response packets for said latency probes; and 

5 recording the dynamic hop count and latency (RTT) data in said latency 

6 management table. 

1 13. (Original) The method of Claim 12, wherein periodic latency probes are sent to a 

2 higher level server of a client by masking said client's IP address in said latency 

3 management table. 

1 14. (Original) The method of Claim 11, further comprising the steps of: 

2 receiving requests for a content server address from said client; 

3 sending a latency metric request to the appropriate content servers; 

4 receiving latency metric data from said content servers; 

5 determining the optimal content server for said client; and 

6 sending said optimal content server's address to said client. 
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1 15. (Currently Amended) The method of Claim 14, wherein said determining step 

2 gathers the expected latency metrics and uses the inverse relationship of the dynamic 

3 hop counts in said latency metric data in a weighted combination with the RTT in 



4 said latency metric data to determine which latency metric data indicates the optimal 

5 content server. 
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